ESC2
This works on the same core principal as ESC1, where a low-privileged user or group has the ability to supply a SubjectAltName (SAN) for any other user or machine in AD. In ESC1 attacks, the flags for the Extended Key Usage (EKU) need to contain "Client Authentication" to be valid.
ESC2 by comparison, is where the EKU is set to "any purpose" or is void of any usage specifications.
The attack method for this follows the same layout as ESC1 although there's a small variation in the prerequisites.
ENROLLEE_SUPPLIES_SUBJECTflag present in the certificate template- Enrolment rights granted to a user or group for which we have access to
- EKU is set to "Any Purpose" or nothing at all
- Manager approval not enabled
- Authorized signature are not required
Enumeration with Certify
.\Certify.exe find /vulnerable /enabled
Linux
certipy find -u 'Moe@Security.local' -p 'Password123' -dc-ip 10.10.10.100 -vulnerable -stdout
Depending on the certificate template configuration, we have two options as stated at the top of this document. If the intended attack path for ESC2 is viable, simply follow the attack steps for ESC1.